Method and System for Device Integrity Authentication

ABSTRACT

Device integrity authentication is performed by receiving, at a second device, a measured integrity value from a first device. The measured integrity value of the first device is compared at the second device to an embedded integrity value associated with the second device. A level of trust for the first device is determined by the second device based on the comparison. Application of a policy to the first device is facilitated by the second device based on the comparison.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 12/860,247 filed Aug. 20, 2010.

TECHNICAL FIELD

This invention relates in general to networked devices and moreparticularly to a method and system for device integrity authentication.

BACKGROUND

Efforts have increased to modernize the nation's aging electrical gridin order to be ready for next generation usage. This modernization hasbrought digitization to the electric grid with many industrial controlcomponents being networked and remotely controlled. However, the detailsof how these components interconnect and communicate have remainedproprietary. With the modernization, more and more devices are added tothe network and implemented with open standards and technology. Anexample of a component being networked is a smart meter deployed at acustomer premises that provides meter readings of electrical usage. Thedeployment of these smart meters is with limited protection or adequatesecurity measures. Some smart meters may be equipped with temperdetection mechanisms that can detect when the meter is opened or movedand shutdown or send an alert signal in response thereto. In manyimplementations, smart meters send critical data from one meter toanother. If one meter in the network is compromised, this critical datacan be used to adversely affect system operation for illicit gain.Current smart meters have no capability to detect an attack remotely, byinsiders, or zero-day attacks that may affect the software executing inthe smart meter.

SUMMARY OF THE DISCLOSURE

From the foregoing, it may be appreciated by those skilled in the artthat a need has arisen to detect for errors in devices and protectnetworked devices from remote software tampering or inside attacks. Inaccordance with the present invention, there is provided a method andsystem for device integrity authentication that substantially eliminatesor greatly reduces disadvantages and problems associated withconventional device security in a network.

According to one embodiment of the present invention, a method fordevice integrity authentication is provided that includes receiving, ata second device, a measured integrity value from a first device. Themeasured integrity value of the first device is compared at the seconddevice to an embedded integrity value associated with the second device.A level of trust for the first device is determined by the second devicebased on the comparison. Application of a policy to the first device isfacilitated by the second device based on the comparison.

Certain embodiments of the invention may provide one or more technicaladvantages. An example of a technical advantage of one embodiment is tohave a second device perform an integrity check on a first device.Another technical advantage is to apply a policy to the first devicebased on the results of the integrity authentication.

Certain embodiments of the invention may include none, some, or all ofthe above technical advantages. One or more other technical advantagesmay be readily apparent to one skilled in the art from the figures,descriptions, and claims included herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and forfurther features and advantages thereof, reference is now made to thefollowing description taken in conjunction with the accompanyingdrawings, wherein like reference numerals represent like parts, inwhich:

FIG. 1 illustrates an example embodiment of a system with networkeddevices;

FIG. 2 illustrates an example embodiment of a device in the network;

FIG. 3 illustrates an example embodiment of a method for performing anintegrity check within the device;

FIG. 4 illustrates an example embodiment of a method for computing ameasured integrity value of the device;

FIG. 5 illustrates an example embodiment of a system with two devicesand a backend server;

FIG. 6 illustrates an example embodiment of a method to allow a seconddevice to determine a level of trust for a first device;

FIG. 7 illustrates an example embodiment of a method involved intransmitting data from the first device to the second device;

FIG. 8 illustrates an example embodiment of a method involved inreceiving data at the second device from the first device.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

FIG. 1 illustrates an embodiment of a system 100 operable to facilitatethe application of a policy to one or more devices 105. In thisembodiment, the system 100 includes a network comprising devices 105,gateways 110, and a backend server 115. Devices 105 may be operable tocommunicate with one another and to the gateways 110. Devices 105, incertain embodiments, may communicate directly with the backend server115 or through a gateway 110. As will be described in more detail in thefollowing figures, under various circumstances, a device 105 may takecertain actions in accordance with a policy. Device 105 may store thepolicy within local storage, or, alternatively, an outside source maycommunicate the policy to device 105. For example, the policy may comefrom other devices 105, from backend server 115 via gateway 110 and/orother devices 105, or from backend server 115 directly.

Devices 105, gateways 110, and backend server 115 may be coupled to anysuitable communication network. A communication network may comprise allor a portion of one or more of the following: a public switchedtelephone network (PSTN), a public or private data network, a local areanetwork (LAN), a metropolitan area network (MAN), a wide area network(WAN), a local, regional, or global communication or computer networksuch as the Internet, a wireline or wireless network, an enterpriseintranet, other suitable communication link, or any combination of anyof the preceding. For example, in certain embodiments, gateways 110 maybe connected by fiber backbone to backend server 115. Additionally,devices 105 may comprise radio transmitters operable to transmit datafrom a device 105 wirelessly to other devices 105, gateways 110, andbackend server 115.

In particular embodiments of system 100, devices 105 may operate assmart meters operable to measure electricity usage for customers of anelectric utility. When devices 105 act as smart meters, they may form amesh network in which management data, control data, and meter data aretransmitted from device to device with each device serving as a relaynode. In these embodiments, backend server 115 may be located at anelectric utility company. Meter data may comprise information about theelectric usage at a particular customer's premises. Control data maycomprise data associated with controlling particular components on oneor more devices 105. Management data may comprise data associated withforming and maintaining the network. For example, management data couldindicate the route that data from a particular device 105 would take inorder to reach backend server 115. As described more fully in thedescription for the figures that follow, a policy may be associated withthese different types of data.

In other embodiments, devices 105 may be any of a range of devices. Forexample, in addition to smart meters, the devices 105 could compriseseveral of the other components of a smart electricity grid. Morebroadly speaking, the devices 105 may comprise one or more components ofany supervisory control and data acquisition (SCADA) or industrialcontrol system. In other embodiments, the devices 105 may be any devicedeployed on a home area network (HAN). One having ordinary skill in theart will appreciate that devices 105 may be employed in a comparativelysmall network such as a HAN or deployed as a large scale network, suchas an electric grid deployed over a neighborhood or city.

FIG. 2 illustrates an embodiment of a device 105 operable to facilitateapplication of a policy. In certain embodiments, device 105 may includea control processing module 205, which may have general control over theoperations and features of device 105. Control processing module 205 maybe coupled to several processing modules operable to perform differentfunctions of device 105 such as integrity check processing module 210,communication processing module 215, measuring processing module 220,and other general processing modules 225. These processing modules mayperform various functions. In some embodiments, control processingmodule 205 also may be coupled to a policy repository 230, a generalstorage 235, and/or a device identifier register 245. Policy repository230 may contain policies to be applied to device 105 under certainconditions. General storage 235 may comprise a storage unit generallyaccessible by control processing module 205 and the other processingmodules included on device 105. Device identifier register 245 may beconfigurable to contain the value of an identifier of device 105.

Communication processing module 215, measuring processing module 220,and general processing modules 225 may perform a wide range offunctions. In certain embodiments, communication processing module 215may operate to transmit or receive communications from other devices105, gateways 110, backend server 115, or any other external source. Italso may operate to assist in determining the route a certaincommunication will take to get to a specific destination. For example,it may determine which other devices 105 to communicate with in orderfor a transmission of data to get to a particular other device 105, aparticular gateway 110, or backend server 115. In embodiments wheredevice 105 is an electric smart meter, measuring processing module 220may measure electricity usage for an electricity user's premises.General processing modules 225 may perform any of a number functionssuch as measuring ambient environment factors proximate to device 105,testing of various elements of device 105, and maintaining anappropriate temperature for device 105. Communication processing module215, measuring processing module 220, and general processing modules 225may operate under the direction of control processing module 205according to a policy stored in policy repository 230.

In embodiments that include device identifier register 245, anidentifier of device 105 may be used to determine what policy shouldapply to device 105 as described in more detail below. As non-limitingexamples, an identifier may comprise a Media Access Control (MAC)address or an (Internet Protocol) IP address. The identifier may behardwired or hardcoded into device identifier register 245 at run-time,or alternatively may be updatable after deployment of device 105. Anidentifier may be unique in the sense that it uniquely identifies aparticular device 105 in a plurality of devices 105. Alternatively, theidentifier contained within device identifier register 245 of aparticular device 105 may be the same as an identifier for one or moreother devices 105. This may happen, for example, in a city with manyneighborhoods. The devices common to a particular neighborhood may sharea common identifier. Certain embodiments of device 105 may include none,one, two, or more device identifier registers 245. They may beconfigured to contain any combination of the types of identifiersdiscussed herein.

In certain embodiments, device identifier register 245 may be in aprotected section of device 105, such that device identifier register245 is more difficult to modify once device 105 is deployed in thefield. The protected section of device 105 could be configured inhardware, software, or firmware. For example, device identifier register245 may be a part of read-only memory or computed from a programconfigured to be non-modifiable.

An embedded integrity value register 240 may store a value which can beaccessed by integrity check processing module 210 when performing itsintegrity check, as further described below. The value stored inembedded integrity value register 240 may be programmed at the time ofthe manufacture of device 105. Alternatively, it may be programmed atsome later time. Embedded integrity value register 240 may be a part ofa protected section of the device 105 in a similar fashion as thatdescribed above for device identifier register 245. In some embodiments,device 105 may employ multiple embedded integrity value registers 240.In certain of these embodiments, the embedded integrity value registersmay employ various formats, such as hardware, firmware, or software.This approach may allow redundancy in the integrity checking feature ofintegrity check processing module 210 as further described below.

In certain embodiments, integrity check processing module 210 may beoperable to perform an integrity check by determining a measuredintegrity value of the device 105 and comparing it to the embeddedintegrity value stored in embedded integrity value register 240.Integrity check processing module 210 may determine the measuredintegrity value of the device 105 by aggregating one or more sectorvalues of other processing modules on the device 105. For example, theintegrity check processing module 210 may determine the sector value ofcommunication processing module 215, measuring processing module 220,and one or more of the general processing modules 225. The integritycheck processing module 210 may then add the sector values of theseprocessing modules such that the measured integrity value is the sum ofthese sector values. In other embodiments, the integrity checkprocessing module 210 may calculate a checksum based on the sectorvalues of one or more predetermined processing modules.

Integrity check processing module 210 may determine the measuredintegrity value using any of a number of formulas while remaining withinthe scope of the present disclosure. In certain embodiments, theformulas may be a function of other factors in addition to the sectorvalues, such as the time of day, the date, the amplitude of ambientlight around the device, the ambient temperature around the device,proximity to a gateway 110 or backend server 115, and/or the amount ofmeter usage in the case where device 105 is a smart meter. In certain ofthese embodiments, the value stored in the embedded value register maychange depending on the values of these other factors in accordance withthe formula. The use of varying formulas when performing the integritycheck may reduce the risk of compromises to device 105 from nefariousthird-parties.

In certain embodiments employing multiple embedded integrity valueregisters 240, the integrity check processing module 210 may beprogrammed to compare the measured integrity value against an aggregateof each of the embedded integrity value registers 240. Alternatively,integrity check processing module 210 may compare the measured integrityvalue against an aggregate of a subset of the integrity value registers240. In some embodiments, integrity check processing module 210 may beconfigured to compute multiple measured integrity values. Integritycheck processing module 210 may compare one or more measured integrityvalues to one or more of the embedded integrity values. Integrity checkprocessing module 210 may report the results of the multiple comparisonsto control processing module 205. A policy stored in policy repositorymay provide instructions depending on the results of the comparison asfurther described below.

In certain embodiments, integrity check processing module 210 may storeintermediate measured values in addition to the measured integrity valuediscussed above, which may also be called a final measured integrityvalue. These intermediate values may be based on a subset of the sectorvalues used to determine the final measured integrity value. Forexample, a first intermediate value may be based on the sector values ofthe communication processing module 215 and the measuring processingmodule 220. A second intermediate value may be based on the sectorvalues of communication processing module 215, measuring processingmodule 220, and one of general processing modules 225. In certainembodiments, the first intermediate value may be the sum of the sectorvalues of communication processing module 215 and measuring processingmodule 220. The second intermediate value may be the sum of the sectorvalues of communication processing module 215, measuring processingmodule 220, and the one of general processing modules 225. Integritycheck processing module 210 may store these intermediate values ingeneral storage 235. Control processing module 205 may access thesevalues from general storage 205 in accordance with a policy stored inpolicy repository 230.

Integrity check processing module 210 may report the result of thecomparison of the measured integrity value to the value in embeddedintegrity value register 240 to control processing module 205. Controlprocessing module 205 may operate to apply one or more policies inpolicy repository 230 based on the results of an integrity checkperformed by integrity check processing module 210. Policy repository230 may be a part of a protected section of the device 105 in a fashionsimilar to that described above for device identifier register 245. Thelevel of protection for policy repository 230 may make the individualpolicies more tamper-proof under certain circumstances.

Depending on the results of the comparison, the policy may instructcontrol processing module 205 to modify the operable features of one ormore processing modules of device 105. In certain embodiments, if thevalues do not match, the policy may instruct the control processingmodule 205 to disable one or more processing modules on the device 105.For example, the control processing module 205 may disable or otherwiserestrict the features of communication processing module 215, themeasuring processing module 220, or one or more of the generalprocessing modules 225. In normal operation the communication processingmodule 215 may be operable with a full feature set such that it cancommunicate with any other device 105 and communicate any type of datato any other device 105. In the instance that the measured integrityvalue does not match the embedded integrity value, the controlprocessing module 205, according to the policy, may completely disablethe features of communication processing module 215 or limit itscommunication features to communicating certain data types. In certainembodiments, the communication processing module 215 may be permitted totransmit metering data, but not allowed to transmit either managementdata or control data. In other embodiments, the policy may directcontrol processing module 205 to disable the entire device 105.

In certain embodiments, the default or normal policy of device 105 mayprovide that certain processing modules of device 105 are disabled. Ifan enabled processing module of device 105 or an outside actor (such asanother device 105) request functions performed by a normally disabledprocessing module of device 105, the policy may require device 105 toperform an integrity check with integrity check processing module 210.In some embodiments, the control processing module 205 may enable thenormally disabled processing module if the integrity check results in amatch in accordance with the description described above. One of skillin the art will recognize that a policy may instruct control processingmodule 205 to begin, cease, or maintain a level of functionality ofvarious processing modules of device 105 according to the results of anintegrity check by integrity check processing module 210.

In the event that a final measured integrity value does not match theembedded integrity value, a policy stored in policy repository 230 mayinstruct the control processing module 205 to retrieve one or more ofthe intermediate values which may be stored in general storage 235. Apolicy stored in policy repository 230 may have different provisionsdepending on certain of the intermediate values. For example, dependingon one or more of the intermediate values, the policy may instructcontrol processing module 205 to disable only one of the processingmodules on device 105. Following this example, it may instruct controlprocessing module 205 to disable one of the general processing modules225 while leaving other general processing modules 225 and communicationprocessing module 215 to maintain their present functionality. As is thecase with a final measured integrity value, certain intermediate valuesmay be expected. Certain intermediate values depend directly on sectorvalues of certain processing modules. The policy may instruct thecontrol processing module 205 to disable the processing modulecorresponding to the sector value, which, when aggregated with themeasured integrity value, yielded the improper result.

In certain embodiments, integrity check processing module 210 may reportthe result of multiple comparisons if, for example, device 105 includesmultiple embedded integrity value registers 240. In embodiments withmultiple embedded integrity value registers 240, the policy stored inpolicy repository 230 may provide various options depending on how manyof the comparisons fail to match. For example, in a device 105 employingthree embedded integrity value registers 240, the policy may allowcontinued functionality if one or two comparisons match successfullywhile the remaining comparison or comparisons result in a non-match. Foreach of these comparisons, one or more intermediate values may have beendetermined according to the procedure described above. Integrity checkprocessing module 210 may store one or more of the determinedintermediate values for each of the comparison in general storage 235for later access by control processing module 205. Control processingmodule 205 may access one or more of the intermediate values if, forexample, a measured integrity value does not match the value stored inan embedded integrity value register 240.

In certain embodiments, a policy stored in policy repository 230 mayinstruct control processing module 205 to allow communication processingmodule 215 to attempt to contact backend server 115 if the integritycheck fails. Backend server 115 may then determine the policy to applyto device 105. To assist backend server 115 in determining whatfunctions the device 105 should be allowed to perform, device 105 maytransmit certain information to backend server 115. This information maycomprise several items including the measured integrity value, the valuestored in device identifier register 245, any intermediate measuredvalues, and/or any other information suitable to assist backend serverto determine a policy to apply to device 105. Based on this information,backend server 115 may transmit a policy for device 105 to apply. Thispolicy, similar to the policy that may be stored in policy repository230, may instruct control processing module 205 to allow the processingmodules 215, 220, and/or 225 to begin, cease, or maintain their currentfunctions. Backend sever 115, in certain embodiments, may transmit apolicy that instructs control processing module 205 to disable device105 completely. In certain embodiments, backend server 115 mayautomatically dispatch a technician to the location of device 105 foron-site troubleshooting.

Backend server 115, in some embodiments, may use an identifiertransmitted by device 105 in determining a policy for device 105 toapply. For example, if backend server determines from the identifierthat device 105 is located such that it is relied on heavily forcommunication routes by other devices 105, it may transmit a policy thatinstructs device 105 to maintain a full level of functionality for itscommunication processing module 215.

FIG. 3 illustrates an embodiment of a method 300 operable to initiate anintegrity check and facilitate application of a policy in accordancewith the results of that integrity check. The method begins at step 305where the integrity check processing module of a device 105 computes themeasured integrity value for device 105. An embodiment of step 305 ismore fully described during the discussion of FIG. 4. At step 310, theembedded integrity value is compared to the measured integrity value ofthe device 105. At step 315 a determination is made as to whether theembedded integrity value matches the measured integrity value. If thevalues match, then the method carries out the policy for a passedintegrity check at step 325. This policy may comprise enabling and/ornot disabling one or more features of one or more processing modules ofdevice 105.

If the values do not match in step 315, the method then carries out thepolicy for a failed integrity check at step 320. This policy maycomprise disabling and/or not enabling one or more features of one ormore processing modules of device 105. The policy may comprise accessingany intermediate values that may be stored in general storage 235. Thepolicy may provide for disabling and/or not enabling one or morefeatures of specific processing modules depending on these intermediatevalues. For example, if a certain intermediate value is not as expected,then the policy may provide for disabling and/or not enabling one ormore features of the specific processing module corresponding to theunexpected intermediate value. The policy may also comprise contacting abackend server 115, sending the backend server 115 certain information,and receiving instruction in the form of a second policy from thebackend server 115. The second policy may be based on the informationsent. The determination as to which policy is to be applied may dependon one or more differences between the measured integrity value and theembedded integrity value.

Other embodiments of the method 300 may comprise steps associated withmultiple embedded integrity values and/or multiple measured integrityvalues. In these embodiments, the method may include steps directed toapplying a policy that makes use of these multiple values. For example,where multiple comparisons take place the policy may favor certaincomparisons over other comparisons in the event that all checks do notpass. Following this example, the policy may provide for disablingand/or not enabling one or more features of a processing module when twoout of three of the comparisons fail. In some embodiments, the policymay depend on the type of embedded integrity value register (e.g.,hardware, software, or firmware) that yielded a failed comparison.

In certain embodiments, a device may be programmed to perform method 300when the device is booted up. In other embodiments, the device mayperform method 300 according to a predetermined schedule. For example,the device 105 may be programmed to perform the method 300 at equallyspaced time intervals four to six times a day. In other embodiments, thedevice 105 may be programmed to perform the method 300 during off-peaktimes, where off-peak times may mean times where network traffic iscomparatively lower than other times. In still other embodiments, thedevice 105 may perform the method 300 in response to a request fromoutside of the device 105. For example, backend server 115 may initiatea system-wide integrity check for all devices 105 within a system 100.

FIG. 4 illustrates an example embodiment of a method 305 for computingthe measured integrity value of a device 105. The method begins at step405 where the list of sectors to measure in the device 105 is retrieved.A sector may correspond or be a part of a particular processing moduleof device 105. In some embodiments, the list of sectors may bepredetermined and stored in a protected section of device 105.

At step 410, the first sector in the list retrieved in step 405 is setas the current sector. At step 415, the current sector value ismeasured. At step 420, the method updates the final measured value ofthe device 105 based on the current sector value. In embodiments wherethe measured integrity depends on the sum of sector values, step 420adds the current sector value to the final measured value. The sum isstored as the final measured value. When the method is complete, thefinal measured value may be reported back as the measured integrityvalue of the device 105.

At step 425, the value stored as the final measured value in step 420 isstored as an intermediate measured value. In some embodiments, thisintermediate measured value may be used in the event that the finalmeasured value does not match the embedded integrity value of the device105. At step 430, a determination is made as to whether there are anymore sectors to measure in the list retrieved during step 405. If thereare more sectors to measure, then the next sector is set as the currentsector at step 435 and the method continues with step 415. At step 430,if there are no more sectors to measure, the method continues with step440. At step 440, the final measured value is returned as the measuredintegrity value for the device 105. In certain embodiments, the method305 may return the intermediate measured values. These can be stored inthe general storage of the device 105.

In certain embodiments, method 305 may perform its steps in varyingorders and with less or more steps than those provided in FIG. 4. Forexample, method 305 may aggregate all the sector values without storingany intermediate values. Alternatively, method 305 may store only someof the intermediate values in accordance with a policy that does nothave provisions for all intermediate values. In some embodiments, method305 may perform in parallel all the calculations needed to determine thefinal measured values and intermediate measured values. Theseembodiments may not require “looping” but may require more systemresources to perform simultaneous calculations.

FIG. 5 illustrates an embodiment of a system 500 operable to facilitateapplication of a policy to a device. Included in the system are a device505, a device 510, and a backend server 515. Devices 505 and 510 mayhave features and components similar to device 105 as depicted in FIG.2. In certain embodiments, device 505 attempts to communicate to device510 or to backend server 515 via device 510. Device 505 may attempt tosend different types of data including control data, management data, ormetering data. Device 505 may also attempt to send diagnostic data tobackend server 515 in response to a failed integrity check. Diagnosticdata may include a measured integrity value, an identifier, anintermediate measured value, and any other information that may helpbackend server 515 to determine an appropriate policy for a device thathas failed an integrity check. Depending on the type of data, device 505may have a policy of performing an integrity check on itself before itallows its communication processing module 215 to send the data. If theintegrity check fails, device 505 may carry out the policy for a failedintegrity check in accordance with method 320. In the instance that theintegrity check passes, device 505 may continue its attempt to send datato device 510 and/or backend server 515. In the event that the integritycheck fails, device 505 may disable or not enable one or more features.In some embodiments, device 505 may attempt to contact backend server515 via device 510. Backend server 515 may then send instructions in theform of a policy back to device 505 via device 510.

In certain embodiments, device 510 may receive a request to communicatefrom device 505 and require device 505 to perform an integrity check.Device 510 may require device 505 to transmit the measured integrityvalue of device 505 to the device 510. Device 510 may then check themeasured integrity value of the device 505 against the embeddedintegrity value of device 510. In the event that the embedded integrityvalue of device 510 and the measured integrity value of the device 505match, device 510 may determine that the device 505 is trustworthy.Device 510 may then allow processing of the data that was sent to device510 from device 505.

In the event that the embedded integrity value of device 510 and themeasured integrity value of device 505 do not match, device 510 may haveseveral options depending on the policy. The policy stored in device 510may be to determine that device 505 is untrustworthy and reject allcommunication with device 505. Another policy may be to contact backendserver 515 for further instruction on how to deal with the incomingcommunication from device 505. In seeking instruction from backendserver 515, device 510 may forward diagnostic data received from device505 such that backend server 515 may determine the appropriate policyfor the device 510 to follow. The determination as to which policy is tobe applied may depend on one or more differences between the measuredintegrity value and the embedded integrity value.

In certain embodiments, the policy (either the one stored on the device510 or the policy received from the backend server 515) may havedifferent provisions depending on the data type. For example, if device505 is attempting to send metering data or diagnostic data, then device510 may allow processing of the data in accordance with its policywithout requiring an integrity check of device 505. If the type of databeing forwarded from device 505 is control data and/or management data,device 510 may restrict the processing on that data in accordance withits policy. This restriction may include rejecting that type ofcommunication or limiting it to certain types of processing.

In certain embodiments, device 505 may attempt to join an existingnetwork of devices if it detects that such a network exists when itboots up. In the event that no network exists, it may attempt to beginits own network. If device 505 attempts to join an existing networkthrough device 510, then device 510 may require device 505 to perform anintegrity check similar to that described in the discussion above.

If admitted to the network, the device 505 may require device 510 tosubmit to an integrity check where the device 510 would have to measureits own integrity value and transmit that to the device 505. The device505 would check the measured integrity value of the device 510 againstthe embedded integrity value of the device 505. A measured integrityvalue may be based on sector values, which may be stored in lessprotected sections of the device 105. These less protected sectors maybe modified sometime after an initial integrity check. This may meanthat the results of an integrity check for a device may change overtime. For example, a device that passed its integrity check at boot-upmay subsequently fail an integrity check after processing various datafrom other devices on the network. Therefore, certain devices mayrequire subsequent integrity checks from certain other devices eventhough the other devices may already be admitted to the network.

In certain embodiments, the device 510 may issue a certificate to thedevice 505 indicating a certain level of trust for device 505. If theembedded integrity value of device 510 matches the measured integrityvalue transmitted by device 505, then the certificate may indicate thatdevice 505 has a high level of trustworthiness. If the embeddedintegrity value of device 510 does not match the measured integrityvalue transmitted by device 505, device 505 may require the device 505to transmit diagnostic data. Based on the diagnostic data, device 510may issue a certificate with an appropriate level of trust according toa policy. The level of trust may be associated with certain allowedtypes of processing on the data transmitted from device 505. Device 510may also send the diagnostic data transmitted by device 505 to backendserver 515. Based on the diagnostic data, backend server 515 mayinstruct device 510 to issue a certificate to device 505 indicating alevel of trust.

Device 505 may present the certificate when attempting futurecommunications with the device 510 such that device 510 may not requiredevice 505 to perform a new integrity check the next time it attempts tocommunicate. In some embodiments, device 510 may keep the certificate inits own general storage. In these embodiments, device 510 may associatethe certificate with an identifier transmitted by device 505. Inparticular embodiments, the certificate may expire after a specifiedamount of time. Even with the presence of a certificate, device 510 mayrequire a new integrity check in certain circumstances. For example,device 510 may require device 505 to perform another integrity check andsend its measured integrity value if the type of data that device 505 isattempting to send is of a critical nature. The use of certificates, incertain embodiments, may require device 510 to retain and managecertificates of the device 505 and other devices not shown in FIG. 5.Certain embodiments of a system 500 may forego the use of certificatesand, instead, require the transmitting device to submit to an integritycheck each time it attempts to communicate.

In certain embodiments, device 505 may attempt to transmit data todevice 510 that was transmitted to device 505 from another device notshown in FIG. 5. In some embodiments, device 510 may determine thatdevice 505 was not the original source of the data. Device 510 mayrequest that the device that transmitted the data to device 505 performan integrity check and send its measured integrity value to device 510.Device 510 may compare this value to its own embedded integrity valueand then process the data depending on the results of the comparison.Note that the device that transmitted the data to device 505 may not bethe “original” source of the data. Device 510 may request an integritycheck from any device in the chain of devices used to route acommunication to device 510. In certain embodiments, the originatingdevice may transmit its measured integrity value with any data that itsends over the network of devices. As such, device 510 may possess themeasured integrity value of the originating device when it receives thetransmission of data from device 505. In some embodiments, device 510may have a policy that requires it to compare its embedded integrityvalue to the measured integrity value of the device it receives the datafrom directly and the device that sent the data originally. Backendserver 515 may also instruct device 510 as to which devices it shouldrequest integrity checks from.

In some embodiments, the embedded integrity values of all devices in anetwork of devices are configured to be the same. The measured integrityvalues of certain devices may be different, however, under varyingcircumstances. For instance, a new neighborhood in a city may have newdevices configured such that their measured integrity values do notmatch the embedded integrity values of the other devices in the city. Inthis situation, the new devices in the new neighborhood may properlyhave different measured integrity values even though they have nototherwise been compromised. In this situation, one of the other devicesmay contact the backend server to determine what policy to apply to datacoming from one of these new devices in accordance with the discussionabove.

All of the options discussed regarding integrity checks for one devicewith respect to FIG. 2 are also available when a first device attemptsto communicate with a second device. For example, device 505 and device510 may be configured with multiple embedded integrity value registers.When device 505 attempts to communicate with device 510, device 510 maycompare the measured integrity value of device 505 against one or moreof the values stored in the embedded integrity value registers of device510. In some embodiments, device 505 may have multiple measuredintegrity values based on various formulas. Device 510 may compare eachmeasured integrity value of device 505 to the one or more embeddedintegrity values of device 510. Device 510 may have policies thatprovide different instructions depending on the results of the variouscomparisons similar to those described with respect to device 105 ofFIG. 2.

FIG. 6 illustrates an embodiment of a method 600 operable to allow asecond device to determine a level of trust of a first device that isattempting to communicate with the second device. The method begins atstep 605 where a second device receives the measured integrity value ofthe first device. In step 610, the second device compares its embeddedintegrity value to the measured integrity value transmitted by the firstdevice. In step 615, a determination is made as to whether the twovalues match. If the two values do not match, then in step 620 thesecond device may determine that the first device to be untrustworthy,and the communication with the first device may be rejected. If themethod determines that the values do match, then at step 625 the seconddevice determines that the first device is trustworthy and continueswith the communication from the first device.

One of skill in the art will recognize that the method 600 could includevarious other steps. For example, the method 600 could include stepsthat determine different levels of trustworthiness for the first devicedepending on the measured integrity value of the first device. Dependingon the level of trustworthiness, the second device may process the dataaccording to the policy stored on the device. In the event that themeasured integrity value of the first device does not match the embeddedintegrity value of the second device, the second device may request thatthe first device transmit more information or diagnostic data. Thisinformation may include the first device's identifier, one or moreintermediate measured values of the first device, and any otherinformation that may assist the second device in determining a level oftrust to assign to the first device. This information may guide thesecond device in determining how to process the data transmitted fromthe first device in accordance with its policy. In some embodiments, themethod may require that the second device contact a backend server. Thesecond device may transmit information or diagnostic data from the firstdevice to assist the backend server in determining the level of trust toassign to the first device.

FIG. 7 illustrates an embodiment of a method 800 operable to facilitateapplication of a policy associated with transmitting data from a firstdevice to a second device. The method begins at step 705 where the firstdevice attempts to send data to a second device. At step 710, adetermination is made as to whether at least a portion of the data thatfirst device is attempting to send is in a protected class. Data may bein a protected class if it corresponds to more critical data. In someembodiments, management data and/or control data may be in a protectedclass while metering data is unprotected. If no portion of the data isin a protected class, the method continues with step 715 where firstdevice continues its attempt to send data to the second device.

If the determination is made that at least a portion of that data thatthe first device seeks to transmit is in a protected class, then themethod continues with step 720 where the measured integrity value of thefirst device is determined. Step 720 may have similar steps as thoselisted for method 305 depicted in FIG. 4. In step 725, the measuredintegrity value of the first device is compared to the embeddedintegrity value of the first device. In step 730, a determination ismade as to whether the embedded integrity value of the first devicematches the measured integrity value of the first device. If the valuesdo match, the method continues with step 715 where the first devicecontinues its attempts to send the data to the second device. If themethod determines that the values do not match, the method continueswith step 735 where the data transmission is restricted in accordancewith a policy. This restriction may be that the data is not sent at allor that a limited amount of data is sent in the transmission. Forexample, the first device may continue its attempts to send thenon-protected portion of the data. In some embodiments, method 700 mayattempt to contact the backend server for further instruction. The firstdevice may send information and/or diagnostic data to the backend serverto assist the backend server in determining whether the first deviceshould continue its attempts to transmit the data to the second device.

FIG. 8 illustrates an embodiment of a method 800 operable to facilitateapplication of a policy associated with receiving data on a seconddevice from a first device. The method begins at step 805 where thesecond device receives data from a first device. In step 810, adetermination is made as to whether at least a portion of the datareceived from the first device is in a protected class. If thedetermination is made that no portion of the data is in a protectedclass, the method continues with step 815 where the second device willprocess the data from the first device in a normal manner according toits policy.

If the determination is made in step 810 that at least a portion of thedata is in a protected class, then the method continues with step 820.In step 820 the measured integrity value of the first device is comparedwith the embedded integrity value of the second device. If the firstdevice did not initially send its measured integrity value with itsinitial transmission of data, then the second device may request thefirst device's measured integrity value at this time. In step 825, adetermination is made as to whether the value of the measured integrityvalue of the first device matches the embedded integrity value of thesecond device. If the values match, then the method continues with step815 where the data transmitted from the first device is processed by thesecond device in a normal manner. If the determination is made in step825 that the values do not match, then the method continues with step830 where the processing of the data transmitted from the first deviceis restricted in accordance with the policy of the second device. Incertain embodiments, the second device may contact the backend server todetermine what processing it should allow on the data transmitted fromthe first device. The second device may send information and/ordiagnostic data of the first device to the backend server to assist thebackend server in determining whether the second device should restrictthe processing of the data sent by the first device.

Modifications, additions, or omissions may be made to the methodsdisclosed herein without departing from the scope of the invention. Themethods may include more, fewer, or other steps. For example, method 800may include the step of requesting from the first device one or moreintermediate measured values. The policy applied to the data sent fromthe first device may depend on one or more of these intermediatemeasured values. Additionally, steps may be performed in any suitableorder.

Modifications, additions, or omissions may be made to the systems andapparatuses disclosed herein without departing from the scope of theinvention. The components of the systems and apparatuses may beintegrated or separated. For example, gateways 110 may be condensed intoone gateway 110. Moreover, the operations of the systems and apparatusesmay be performed by more, fewer, or other components. For example, theoperations of communication processing module 215 and measuringprocessing module 220 may be performed by one component, or theoperations of control processing module 205 may be performed by morethan one component. Additionally, operations of the systems andapparatuses may be performed using any suitable logic comprisingsoftware, hardware, and/or other logic. As used in this document, “each”refers to each member of a set or each member of a subset of a set.

A component of the systems and apparatuses disclosed herein may includean interface, logic, memory, and/or other suitable element. An interfacereceives input, sends output, processes the input and/or output, and/orperforms other suitable operation. An interface may comprise hardwareand/or software.

Logic performs the operations of the component, for example, byexecuting instructions to generate output from input. Logic may includehardware, software, and/or other logic. Logic may be encoded in one ormore tangible media and may perform operations when executed by acomputer. Certain logic, such as a processor, may manage the operationof a component. Examples of a processor include one or more computers,one or more microprocessors, one or more applications, and/or otherlogic.

In particular embodiments, the operations of the embodiments may beperformed by one or more computer readable media encoded with a computerprogram, software, computer executable instructions, and/or instructionscapable of being executed by a computer. In particular embodiments, theoperations of the embodiments may be performed by one or more computerreadable media storing, embodied with, and/or encoded with a computerprogram and/or having a stored and/or an encoded computer program.

A storage unit, a repository, and a register may comprise memory. Amemory stores information. A memory may comprise one or morenon-transitory, tangible, computer-readable, and/or computer-executablestorage media. Examples of memory include computer memory (for example,Random Access Memory (RAM) or Read Only Memory (ROM)), mass storagemedia (for example, a hard disk), removable storage media (for example,a Compact Disk (CD) or a Digital Video Disk (DVD)), database and/ornetwork storage (for example, a server), and/or other computer-readablemedium.

Although this disclosure has been described in terms of certainembodiments, alterations and permutations of the embodiments will beapparent to those skilled in the art. Accordingly, the above descriptionof the embodiments does not constrain this disclosure. Other changes,substitutions, and alterations are possible without departing from thespirit and scope of this disclosure, as defined by the following claims.

What is claimed is:
 1. A method for device integrity authentication, comprising: receiving, at a second device, a measured integrity value from a first device; comparing, using the second device, the measured integrity value of the first device to an embedded integrity value associated with the second device; determining, by the second device, a level of trust for the first device based on the comparison.
 2. The method of claim 1, wherein the level of trust is one of a plurality of levels of trust that can be determined based on the comparison.
 3. The method of claim 2, wherein the plurality of levels of trust include a low level of trust, a medium level of trust, and a high level of trust.
 4. The method of claim 3, wherein determining the level of trust includes determining that the first device has a low level of trust in response to the measured integrity value not matching the embedded integrity value.
 5. The method of claim 1, further comprising: facilitating, on the second device, application of one of a plurality of communication policies associated with communicating with the first device based on the determined level of trust.
 6. The method of claim 5, wherein one of the plurality of policies includes restricting functions of the first device based on the determined level of trust.
 7. The method of claim 5, wherein one of the plurality of policies includes rejecting all communications with the first device based on the determined level of trust.
 8. The method of claim 1, wherein determining the level of trust includes: communicating, by the second device, with a backend server in response to the measured integrity value not matching the embedded integrity value; receiving, at the second device, an indication from the backend server an indication of the level of trust for the first device.
 9. The method of claim 1, wherein determining the level of trust includes: communicating, by the second device, with a backend server in response to the measured integrity value not matching the embedded integrity value; receiving, at the second device, one of a plurality of communication policies associated with communicating with the first device from the backend server.
 10. The method of claim 1, wherein determining the level of trust includes: requesting additional information from the first device in response to the measured integrity value not matching the embedded integrity value;
 11. The method of claim 10, wherein the additional information includes an identity of the first device and one or more intermediate measured integrity values.
 12. A system for device integrity authentication, comprising: an integrity check processing module operable to: receiving a measured integrity value from a first device; comparing the measured integrity value of the first device to an embedded integrity value associated with the integrity check processing module; a control processing module operable to determine a level of trust for the first device based on the comparison.
 13. The system of claim 12, wherein the level of trust is one of a plurality of levels of trust that can be determined based on the comparison.
 14. The system of claim 13, wherein the plurality of levels of trust include a low level of trust, a medium level of trust, and a high level of trust.
 15. The system of claim 14, wherein determining the level of trust includes determining that the first device has a low level of trust in response to the measured integrity value not matching the embedded integrity value.
 16. The system of claim 12, wherein the control processing module is further operable to facilitate application of one of a plurality of communication policies associated with communicating with the first device based on the determined level of trust.
 17. The system of claim 16, wherein one of the plurality of policies includes restricting functions of the first device based on the determined level of trust.
 18. The system of claim 16, wherein one of the plurality of policies includes rejecting all communications with the first device based on the determined level of trust.
 19. The system of claim 12, wherein the control processing module is further operable to: communicate with a backend server in response to the measured integrity value not matching the embedded integrity value; receive an indication from the backend server an indication of the level of trust for the first device.
 20. The system of claim 12, wherein the control processing module is further operable to: communicate with a backend server in response to the measured integrity value not matching the embedded integrity value; receive one of a plurality of communication policies associated with communicating with the first device from the backend server.
 21. The system of claim 12, wherein the control processing module is further operable to: request additional information from the first device in response to the measured integrity value not matching the embedded integrity value;
 22. The system of claim 21, wherein the additional information includes an identity of the first device and one or more intermediate measured integrity values. 